[アップデート] AppStream 2.0 で SAML 2.0 Federated User を利用する際にアプリケーションの選択ができる様になりました
しばたです。
先日Amazon AppStream 2.0のサービスが更新され、SAML 2.0を使ったFederated Userを使用する場合にユーザーの属性によって利用可能なアプリケーションを選択できる機能(Application Entitlements)が増えました。
AWSのアナウンスは以下となります。
Application Entitlements?
Application EntitlementsはAWS上だとそのまま「アプリケーションエンタイトルメント」と呼称する様ですが、無理やり日本語にすると「アプリケーション利用資格」といったところでしょうか。
AppStream 2.0のイメージで公開するアプリケーションに対する利用資格となり、ユーザーごとにイメージ内で利用可能なアプリケーションを制御する仕組みとなります。
要はこういう事です。
たとえば「Calc」「Firefox」「Eclipse」の3つのアプリケーションを公開するイメージ(設定上はStackになる)があったとして、経理担当者には「CalcとFirefoxだけ公開」、開発者には「EclipseとFirefoxだけ公開」といった制御ができる様になりました。
技術的にはAppStream 2.0のSAML認証でやり取りできる新しい属性(PrincipalTag
)が増え、IdPから属性情報をAWSに送ることで使用可能なアプリケーションのフィルタリングを行う形となります。
SAML 2.0に関わる機能拡張として実装されているためユーザープールのユーザーではこの機能は利用できません。[1]
新しい属性の一覧は以下の通りです。
https://aws.amazon.com/SAML/Attributes/PrincipalTag:roles
https://aws.amazon.com/SAML/Attributes/PrincipalTag:department
https://aws.amazon.com/SAML/Attributes/PrincipalTag:organization
https://aws.amazon.com/SAML/Attributes/PrincipalTag:groups
https://aws.amazon.com/SAML/Attributes/PrincipalTag:title
https://aws.amazon.com/SAML/Attributes/PrincipalTag:costCenter
https://aws.amazon.com/SAML/Attributes/PrincipalTag:userType
これらの属性情報を必要に応じてAWSに渡してやります。
試してみた
それでは早速この機能を試してみます。
今回はこちらのブログの内容に倣ってIdPにAzure ADを使う形とします。
AppStream 2.0標準で提供されているサンプルイメージを使い、Azure ADのグループに応じて利用可能なアプリケーションを切り替えてみます。
1. AppStream 2.0 Stackの準備
今回はAWSから提供されているサンプルイメージAmazon-AppStream2-Sample-Image-02-04-2019
を使いFleetとStackを準備します。
(今回はmy-saml-stack
という名前のStackを用意)
Stackの詳細情報に新たに「Application Entitlements」欄が増えていますので「Create entitlement」をクリックします。
この「Entitlement」で属性に応じた利用アプリケーションの設定を行います。
ここでは経理担当向けにkeiri-apps
という名前で「groups
属性の値が経理
という文字列」だった場合に公開アプリケーション「calc
とfirefox
」だけを利用可能としてみました。
同様に開発者向けのEntitlementdev-apps
も作り、「groups
属性の値が開発者
という文字列」だった場合に公開アプリケーション「eclipse
とfirefox
」だけを利用可能としています。
結果こんな感じになります。
2. Azure AD側設定
Azure AD側設定については、基本的にこちらの記事の通りではあるのですが、AppStream 2.0サービスの更新により一部手順が変わっています。
2-1. [AWS] IAM IDプロバイダー設定
Azure ADでエンタープライズアプリケーションを作成しフェデレーションメタデータを取得したのちAWS側でIAM IDプロバイダーの設定を行います。
このIAM IDプロバイダーに設定する信頼関係の設定が少し異なり"sts:TagSession"
に対する許可も増やしてやる必要があります。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::<Your account id>:saml-provider/<IAM Provider name>"
},
"Action": [
"sts:AssumeRoleWithSAML",
"sts:TagSession"
],
"Condition": {
"StringEquals": {
"SAML:aud": "https://signin.aws.amazon.com/saml"
}
}
}
]
}
比較用に従来のアクセスコントロールポリシーリストを以下に記載しておきます。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::<Your account id>:saml-provider/<IAM Provider name>"
},
"Action": "sts:AssumeRoleWithSAML",
"Condition": {
"StringEquals": {
"SAML:sub_type": "persistent"
}
}
}
]
}
ちなみにアクセス権限については従来同様に設定してください。
2-2. [Azure AD] SAML 2.0クレーム設定
続けてAzure AD側でSAML 2.0のクレーム設定をする際に、従来は
https://aws.amazon.com/SAML/Attributes/Role
https://aws.amazon.com/SAML/Attributes/RoleSessionName
https://aws.amazon.com/SAML/Attributes/SessionDuration
の3クレームを記述しますが、Application Entitlementsを利用する場合、これに加えて最初に紹介した新属性を必要に応じて追加してやります。
今回はAzure ADユーザーの所属グループに応じて利用アプリケーションを切り替えたいのでhttps://aws.amazon.com/SAML/Attributes/PrincipalTag:groups
属性に対するクレームを追加します。
Azure ADエンタープライズアプリケーションのSAMLクレームの追加画面で以下の様に
- 名前 :
PrincipalTag:groups
- 名前空間 :
https://aws.amazon.com/SAML/Attributes
を指定します。
そして画面下の「要求条件」をクリックし利用メンバーに応じて属性値を変えてやります。
細かい手順までは説明しませんが、上図の場合だと
- 1行目で「Azure ADユーザーの所属グループが経理グループ」の場合「属性値 : "経理"」をAWSに渡す
- 2行目で「Azure ADユーザーの所属グループが開発者グループ」の場合「属性値 : "開発者"」をAWSに渡す
となります。
これでクレームを保存し、最終的に4つのクレームを渡す様に設定します。
2-3. その他設定
その他手順については前掲リンク先記事の通りにしてください。
3. 接続確認
SAML 2.0の設定が完了した後は接続確認をします。
今回はAzure ADの検証ユーザーとして「経理グループ」に所属する担当者01ユーザー
と「開発者グループ」に所属する担当者02ユーザー
を用意しました。
まずは担当者01ユーザーでhttps://myapps.microsoft.com
に接続してAppStream 2.0を利用します。
この様にApplication Entitlementsで設定した「CalcとFirefoxのみ」が利用可能アプリケーションとしてリストアップされます。
次に担当者02ユーザーでAppStream 2.0を利用すると「EclipseとFirefoxのみ」リストアップされます。
この様に利用者の属性に応じて利用アプリケーションを分けることができます。
補足1 : 対象外ユーザーによる利用
ちなみにどちらのグループにも所属しないユーザーで試してみたところ「利用可能アプリケーションなし」になりました。
補足2 : 後からApplication Entitlementsを削除した場合
また、一度設定したApplication Entitlements設定を後から削除した場合は従来どおりイメージに登録されている全アプリケーションが表示されます。
余談 : SAML 2.0 Federated UserのMulti Stack Accessサポートについて
今回Application Entitlementsの追加に合わせて、SAML 2.0で使用するリレー状態のURLからStack名を除外し複数のStackから条件にマッチするアプリケーションをリストアップできる様になったとのことです。
項目 | 値 |
---|---|
従来のリレー状態 | https://relay-state-region-endpoint?stack=stackname&accountId=aws-account-id-without-hyphens |
現在指定可能なリレー状態 | https://relay-state-region-endpoint?accountId=aws-account-id-without-hyphens |
イメージとしてはこんな感じでしょう。(未検証)
今回この機能は試しませんが、詳細は以下のドキュメントに記載されていますので参照してください。
最後に
以上となります。
これまでは利用者ごとで利用アプリケーションを分けたい場合はイメージ(およびStack)自体を分けるしかありませんでした。
このため似た様なイメージを複数運用していた環境もあったことでしょう。
今回の更新によりその様なイメージを集約することができるため運用負荷を下げることが可能になりました。
ユーザー毎の属性情報を使うためSAML 2.0 Federated Userのみ利用可能な制限はあるものの環境によっては非常に便利に使えると思います。
ユーザープールのユーザーでは追加の属性情報を持てない ↩︎